1. Field of the Invention
The present invention relates generally to a method and system for requesting and granting Push-To-Talk (PTT) over Cellular (PoC) user media transmission right. In particular, the present invention relates to a method and system optimized for a PoC user to request and receive media transmission right in a PoC network in which queuing is not supported.
2. Description of the Related Art
The significant development of mobile communication and the spread of communication networks have contributed to various extra services and applications using a cellular phone. At the same time, demand among cellular phone users for various extra services, such as a positioning service, a multimedia service, and a Push-To-Talk (PTT) service, is increasing. Among these extra services, the PTT service supports various supplementary functions such as an instant messenger function and a status display function, as well as supporting a group call and a voice call, which are also provided by an existing radio or a Trunked Radio System (TRS).
Currently, standardization of a PTT-over-Cellular (PoC) service, which employs the PTT function in a mobile communication network, is actively being developed. One unique feature of the PoC service, which is distinguished from existing mobile communication services, is that a user can participate in a plurality of PoC sessions and can move among the PoC sessions to use a call service. A requirement that the user can move among the plurality of PoC sessions to use the call service is specified in the Open Mobile Alliance (OMA), which is a forum for specifying mobile communications services.
FIG. 1 is a schematic diagram of a conventional PoC service system. Referring to FIG. 1, a PoC client 102, which is a service requester installed in a PoC user terminal 100, is connected to a Session Initiation Protocol/Internet Protocol (SIP/IP) core network 120, which supports SIP and IP multimedia functions, via an access network 110.
The PoC client 102 resides in the PoC user terminal 100 to provide access to the PoC service. The PoC client 102 mainly serves a PoC user to initiate a PoC session, participates in a PoC session that is currently proceeding, and terminates a PoC session. In addition, the PoC client 102 acts to make and transfer a talk burst, support an instant personal alert, and perform authentication when accessing the PoC service. Hereinafter, unless otherwise stated, the PoC client 102 is assumed to be the same as a PTT service subscriber.
The SIP/IP core network 120 is connected to a PoC server 150, a PoC Extensible Markup Language Document Management Server (XDMS) 140, and a PoC box 180 in order to support the PoC service.
The PoC server 150 has a controlling PoC function for maintaining and managing a PoC session, or a participating PoC function for participating in a PoC session established for a one-to-one PoC call or a one-to-many PoC call.
A function of the PoC server 150 is classified into a Controlling PoC Function (CF) for generally maintaining and managing a PoC session and a Participating PoC Function (PF) for maintaining and managing each PoC session, which will be described in more detail with reference to Tables 1 and 2.
TABLE 1Controlling PoC Function (CF) provides centralized PoC session handlingProvides the centralized Media distributionProvides the centralized Talk Burst Arbitration functionality includingtalker identificationProvides SIP session handling, such as SIP session origination,termination, etc.Provides policy enforcement for participation in group sessionsProvides the participants informationCollects and provides centralized media quality informationProvides centralized changing reportMay provide transcoding between different codecsSupports Talk Burst Control Protocol Negotiation
As shown in Table 1, the CF serves to generally manage a PoC session among functions of the PoC server 150. The PoC server 150 receives requests for a floor (right to talk) from PoC clients, arranges an order in which to give the clients the floor, and gives the clients the floor in that order. The PoC server 150 also distributes a talk burst from a specific PoC client to all PoC clients participating in a group PoC call, and provides information of the PoC clients participating in the group PoC call.
As shown in Table 2 below, the PF manages a PoC session between the CF and each PoC client. In particular, the PF acts to relay the floor between the PoC client and the CF when the PoC client requests the floor or when the CF gives the floor to the PoC client. In addition, the PF serves to relay media between the CF and the PoC client, provide transcoding between different codecs, and provide a filtering function for filtering one of two PoC sessions chosen by a user when there is simultaneous talking in two simultaneous PoC sessions.
TABLE 2Participating PoC Function (PF) provides PoC session handlingMay provide the Media relay function between PoC Client and ControllingPoC serverMay provide user media adaptation proceduresMay provide the Talk Burst control message relay function betweenPoC Client and Controlling PoC serverProvides SIP session handling, such as SIP session origination,termination, etc., on behalf of the represented PoC ClientProvides policy enforcement for incoming PoC session (e.g. accesscontrol, incoming PoC session barring, availability status, etc.)May collect and provide media quality informationProvides the participant charging reportsMay provide filtering of the media streams in the case ofsimultaneous sessionsMay provide transcoding between different codecsMay support Talk Burst Control Protocol NegotiationStores the current Answer Mode and Incoming PoC Session Barringpreferences of the PoC Client
An aggregation proxy server 160 acts to collect requests of all entities using an XML Configuration Access Protocol (XCAP) in the PoC service system and transfer the requests to corresponding entities.
In order to use a PoC call service, the PoC user registers his/her PoC address in the SIP/IP core network 120. The SIP/IP core network 120 stores information regarding the PoC user at the request of the PoC user. Thus, when another PoC user tries to request a group PoC call, the PoC user registers his/her information in the SIP/IP core network 120 in advance as described above, and requests the group PoC call to his/her SIP/IP core network 120 by using group identification information transmitted from the PoC XDMS 140. The SIP/IP core network 120 performs address determination and domain location determination using information on the call requesting PoC user, and then transfers a PoC call request to a home PoC server with which the call requesting PoC user is registered. In regard to the PoC call request, the PoC server 150 prepares for establishment of a PoC session, obtains each user's information from the PoC XDMS 140, and then transfers a PoC call request signal to a corresponding SIP/IP core network 120. Here, in the case of a PoC call request to users within an Intradomain, the PoC server 150 performs both the CF and PF. The PoC server 150, which manages a call-requested PoC user, requests a PoC call to the PoC user after the SIP/IP core network 120 performs the location determination procedure, by using information on the PoC user that is transmitted to the PoC server 150. If the call-requested PoC user transmits an OK response to the call requesting PoC user, a PoC call is connected. When a PoC call is not connected due to a state of another PoC user regardless of a PoC call request of a PoC user, the PoC user can store his or her voice or media desired to transmit, using the PoC box 180.
FIG. 2 is a signaling diagram of a process of requesting and granting a media transmission right between a PoC client and a PoC server (CF) in a PoC network in which queuing is not supported.
Referring to FIG. 2, if the PoC client transmits a media transmission right request (Media Burst Control Protocol (MBCP) Request) message for requesting the media transmission right to the PoC server (CF) in step 200, the PoC server (CF) determines in step 202 whether a current state corresponds to a media transmission denial condition. The media transmission denial condition is any of five state conditions of the denial reasons described below. It is assumed that the current state does not correspond to a condition for granting the media transmission right to the PoC client.
If it is determined in step 202 that the current state corresponds to a media transmission denial condition, in step 204, the PoC server transmits a media transmission right request denial (MBCP Deny) message to the PoC client that has requested the media transmission right.
The PoC client, which has received the MBCP Deny message, informs a PoC user of a reason for denial contained in the MBCP Deny message.
The five reasons for denial defined in an OMA PoC specification are described below:
1. When another PoC user is transmitting media;
2. An internal error of a PoC server acting as a controlling PoC function;
3. When only a PoC client, which has requested a floor, in a relevant session;
4. When a penalty time (a retry after timer operation) is applied since the maximum media transmission time was not observed in previous media transmission; and
5. When a subscribing state of a PoC user is a listen only state.
That is, if the current state corresponds to one of the five denial reasons, the PoC server, which has received the MBCP Request message, transmits the MBCP Deny message to the PoC client without granting the media transmission right. The PoC server determines in step 206 whether the current state is free from the media transmission denial condition.
Thereafter, in order for the PoC client to obtain the media transmission right again, if a media transmission idle (MBCP Idle) message, which is a message having information that no PoC user exists in a PoC session, is received in step 208, the PoC client informs the PoC user of this state. If a request for the media transmission right is input by the PoC user, the PoC client can request a floor again by transmitting the MBCP Request message to the PoC server in step 210.
FIG. 3 is a message format of the MBCP Deny message transmitted from the PoC server.
Referring to FIG. 3, the first 2-bit field (300) is for a Real-time Transport Protocol (RTP) Version V. In the case of the present invention, the RTP version is 2. The second 1-bit field (301) is for a Padding bit P. It can be seen that if the padding bit P is given, one or two padding octets that are not contained in a payload, are added. The third 5-bit field (302) indicates a subtype. It can be seen by referring to an OMA PoC User Plane specification which function of a Time Burst Control Protocol (TBCP) a Real-time Transport Control Protocol Application (RTCP APP) packet performs using the subtype. For example, in the case of the MBCP Deny message, the subtype has a value defined as 00011.
The fourth 1-byte field (303) is for a Packet Type (PT), and is shown as PT=204, which indicates that this message is an RTCP APP packet. The fifth 2-byte field (304) is for a length field. If a value of 2 is used in the length field, this indicates that the message has two 4-byte octets. If the value is followed by a payload, this indicates a length of the payload, i.e. how many 4-byte octets exist in the payload. In the case of the MBCP Deny message, a total size of the MBCP Deny message is determined according to a reason phrase.
The sixth 4-byte field (305) is for a Synchronization SouRCe (SSRC) field. This field contains a synchronization source to discriminate senders of the RTCP APP message. The seventh 4-byte field (306) is expressed by an American Standard Code for Information Interchange (ASCII), which has a function of discriminating a PoC version according to the OMA PoC specification.
Reason code (307) related fields have a value indicating a denial reason. Four denial reasons defined in the OMA PoC specification are described below:
1. If the code value is 1, another PoC user has permission.
2. If the code value is 2, the media transmission right cannot be acquired due to an internal error of a PoC server.
3. If the code value is 3, a retry-after value has not been terminated yet. The retry-after value is a value of a timer activated by the PoC server when a PoC user transmitted media by spending his/her entire allowed time. That is, the timer is a penalty timer. Thus, the PoC user cannot acquire the media transmission right regardless of a media transmission right request while the timer is operating.
4. If the code value is 4, since the priority of the PoC user who has requested the media transmission right is set to ‘Listen only’, the PoC user cannot transmit but can receive media in a PoC session.
As described above, if a PoC user requests a media transmission right from a PoC server by means of a PoC client, and if the PoC user receives the MBCP Deny message in response, the PoC user can request the media transmission right again only after receiving an MBCP Idle message from the PoC server. That is, the PoC user must wait to receive the MBCP Idle message if the PoC user has received the MBCP Deny message.